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DETAILED ACTION 



Claim Objections 



1 . Claims 2, 8-9, 1 3, 1 8, 24-25, and 35-36 are objected to because of the following 
informalities: 

Claim 2 states, "...wherein the layer 2 multicast channel is an Ethernet MAC 
address and the layer 3 multicast channel is an IP address." Addresses may be used 
as an identifier for a channel, but addresses are not channels. It is recommended that 
the claim be amended to state, "...wherein the layer 2 multicast channel is identified by 
an Ethernet MAC address and the layer 3 multicast channel is identified by an IP 
address." Claims 8-9, 18, 24-25, and 35-36 all contain limitations similar to the 
limitations of claim 2 and should be amended accordingly. 

The apparatus claim 13 claims "a forwarding engine coupled with the control 
engine", but there is no further discussion of the function of the forwarding engine in the 
claim. It appears they may be a typo on line 4 of claim 13 that states, "...the control 
engine to receive a". It is recommended that "the control engine" be changed to "the 
forwarding engine" such that the function of the forwarding engine is claimed. 

Many of the claims contain acronyms. It is recommended that the first 
appearance of each acronym in the claims be defined so as to avoid confusion 
regarding the meaning of the acronyms. 

Appropriate correction is required. 
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Claim Rejections - 35 USC § 102 

2. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 

form the basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(a) the invention was known or used by others in this country, or patented or described in a printed 
publication in this or a foreign country, before the invention thereof by the applicant for a patent. 

3. Claims 1-10 are rejected under 35 U.S.C. 102(a) as being anticipated by Song et 
al. IP Multicasting and Broadcasting for PPPoE Protocol, Network Working Group, 
Internet Draft, August 2001 (as supplied by the Applicant's IDS filed on 10/22/01). 

With respect to claim 1, Song et al. discloses a computer implemented method 
(See sections 3.1-3.3 of Song et al. for reference to applicability scenarios in 
which the methods of Song et al. are implemented by computers). Song et al. also 
discloses determining a PPPoE client to be multicast capable (See part D in section 2 
of Song et al. for reference to a PPPoE client notifying a PPPoE server that it 
supports multicasting). Song et al. further discloses determining a layer 2 multicast 
channel from a layer 3 multicast channel (See part B in section 2 of Song et al. for 
reference to using an IP address of a channel, which is a layer 3 address, to 
create an Ethernet multicast address of a channel, which is a layer 2 address). 
Song et al. also discloses transmitting multicast traffic for the layer 2 multicast channel 
as PPPoE multicast traffic in a PPPoE multicast session to the PPPoE client (See part 
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B in section 2 of Song et al. for reference to transmitting a muiticast data paclcet 
to a user as muiticast traffic in a PPPoE muiticast cfiannel). 

With respect to claim 7, Song et al. discloses a computer implemented method 
(See sections 3.1-3.3 of Song et ai. for reference to applicability scenarios in 
which the methods of Song et ai. are implemented by computers). Song et al. also 
discloses translating a layer 3 multicast channel to a layer 2 multicast channel (See part 
B in section 2 of Song et ai. for reference to using an IP address of a channel, 
which is a layer 3 address, to create an Ethernet muiticast address of a channel, 
which is a layer 2 address). Song et al. further discloses receiving a multicast paclcet, 
encapsulating the multicast packet with a PPPoE encapsulation, indicating the layer 2 
multicast channel and a PPPoE multicast session identifier in the PPPoE encapsulation, 
and transmitting the encapsulated multicast packet (See part B in section 2 of Song et 
ai. for reference to receiving a muiticast IP paclcet that is to be sent, 
encapsulating the packet with a PPPoE encapsulation that identifies the frame as 
a multicast session using the ETI-iER_TYPE field and indicates the specific 
multicast channel using an Ethernet multicast address, and for reference to 
sending, or transmitting, the encapsulated muiticast paclcet). 

With respect to claim 2, Song et al. discloses that the layer 2 multicast channel 
Is identified by an Ethernet MAC address and the layer 3 multicast channel is identified 
by an IP address (See part B in section 2 of Song et al. for reference to the layer 2 
and layer 3 addresses being an Ethernet address and an IP address respectively). 
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With respect to claim 3, Song et al. discloses determining a client to be 
multicast capable comprises receiving a session request message including a tag 
indicating PPPoE multicast capability from the PPPoE client (See parts C-D In section 
2 of Song et al. for reference to PPPoE clients sending session requests using a 
JoinLocalGroup operation and for reference setting a TYPE field to 0x2 Indicating 
that the client is multicast capable). 

With respect to claim 4, Song et al. discloses that the PPPoE multicast traffic 
identifies a PPPoE multicast session identifier and the layer 2 multicast channel (See 
part B in section 2 of Song et a I. for reference to the PPPoE multicast packets of 
the PPPoE multicast traffic indicating a multicast session using the ETHERJTYPE 
field and indicating a specific layer 2 multicast channel using the Ethernet 
multicast address). 

With respect to claim 5, Song et al. discloses the PPPoE client listening for 
PPPoE multicast traffic on the layer 2 multicast channel (See part B in section 2 of 
Song et al. for reference to a client accepting Ethernet multicast packets if the 
client has joined the group receiving the Ethernet multicast packets, meaning that 
the client must listen for the multicast traffic on the layer 2 multicast channel in 
order to receive the Ethernet multicast packets). 

With respect to claim 6, Song et al. discloses the PPPoE dine decapsulating 
traffic from the PPPoE if the PPPoE client is listening on the layer 2 multicast channel 
(See page B in section 2 of Song et al. for reference to clients accepting Ethernet 
multicast packets if they have joined the multicast group, meaning the client must 
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decapsulate the packets of the traffic in order to properly decode and use the 
packets). 

With respect to claim 8, Song et ai. discloses that the layer 2 multicast channel 
is identified by an Ethemet Media Access Control address (See part B in section 2 of 
Song et al. for reference to the layer 2 multicast channel being identified by an 
Ethernet multicast address). 

With respect to claim 9, Song et al. discloses that the layer 3 multicast channel 
is identified by an Internet Protocol address (See part B in section 2 of Song et al. for 
reference to the layer 3 multicast channel being Identified by an IP multicast 
packet's IP address). 

With respect to claim 10, Song et al. discloses that the PPPoE multicast 
session Identifier is a reserved PPPoE session identifier (See part B in section 2 of 
Song et al. for reference to setting the ETHER_TYPE field of the frame to 0x8864, 
which is a reserved value indicating a multicast PPPoE session). 



Claim Rejections - 35 USC § 103 



4. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, If the differences between the subject nnatter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the Invention was made. 
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5. Claims 11-12 and 34-37 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Song et al. in view of Unitt et al. (U.S. Publication US 
2004/0240466A1). 

With respect to claim 34, Song et al. discloses a device performing operations 
including generating a layer 2 multicast channel form a layer 3 multicast channel (See 
part B in section 2 of Song et al. for reference to using an IP address of a channel, 
which is a layer 3 address, to create an Ethernet multicast address of a channel, 
which is a layer 2 address). Song et al. also discloses receiving a multicast packet, 
encapsulating the multicast packet with a PPPoE encapsulation, Indicating the layer 2 
multicast channel and a PPPoE multicast session identifier in the PPPoE encapsulation, 
and transmitting the encapsulated multicast packet (See part B in section 2 of Song et 
al. for reference to receiving a multicast IP packet that is to be sent, 
encapsulating the packet with a PPPoE encapsulation that Identifies the frame as 
a multicast session using the ETHER_TYPE field and Indicates the specific 
multicast channel using an Ethernet multicast address, and for reference to 
sending, or transmitting, the encapsulated multicast packet). While Song et al. 
does disclose these operation being implemented in multiple scenarios by multiple 
devices (See sections 3.1 -3.3 of Song et al. for reference to an Ethernet switch, a 
CMTS, and a DSLAM implementing the operations). Song et al. does not specifically 
discloses using a machine-readable medium providing instructions executed by one or 
more processors. 
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With respect to claim 34, Unitt et al., in the field of communications, discloses 
using a machine-readable medium providing instructions executed by one or more 
processors (See page 3 paragraph 43 and Figure 1 of Unitt et al. for reference to 
using router that includes a process executing instructions to provide multicast 
Ethernet data). Using a machine-readable medium providing instructions executed by 
one or more processors has the advantage of allowing the device to be flexible since 
the operation of the device may be changed by changing the software of the instructions 
without requiring the hardware to be replaced. 

It would have been obvious for one of ordinary skill in the art at the time of the 
invention, when presented with the work of Unitt et al., to combine using a machine- 
readable medium providing Instructions executed by one or more processors, as 
suggested by Unitt et al., with the system and method of Song et al., with the motivation 
being to allow the device to be flexible since the operation of the device may be 
changed by changing the software of the instructions without requiring the hardware to 
be replaced. 

With respect to claim 35, Song et al. discloses that the layer 2 multicast 
channel is identified by an Ethernet Media Access Control address (See part B in 
section 2 of Song et al. for reference to the layer 2 multicast channel being 
identified by an Ethernet multicast address). 

With respect to claim 36, Song et al. discloses that the layer 3 multicast 
channel is identified by an Internet Protocol address (See part B in section 2 of Song 
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at al. for reference to the layer 3 multicast channel being identified by an IP 
multicast packet's IP address). 

With respect to claim 37, Song et al. discloses that the PPPoE multicast 
session identifier is a reserved PPPoE session identifier (See part B in section 2 of 
Song et a I. for reference to setting the ETHER.TYPE field of the frame to 0x8864, 
which is a reserved value indicating a multicast PPPoE session). 

With respect to claims 1 1-12, Song et al. does not specifically disclose that the 
multicast packets are video packets and collaboration application packets. 

With respect to claims 11-12, Unitt et a!., in the field of communications, 
discloses multicast Ethernet packets that are video packets and collaboration 
application packets (See page 3 paragraph 44 and page 5 paragraph 98 of Unitt et 
al. for reference to streaming video packets and for reference to streaming other 
types of multicast services including applications). Multicasting Ethernet packets 
that are video packets and collaboration application packets has the advantage of 
allowing multiple users to view the same video or work on the same application at the 
same time in real time. 

It would have been obvious for one of ordinary skill in the art at the time of the 
invention, when presented with the work of Unitt et al., to combine multicasting Ethernet 
packets that are video packets and collaboration application packets, as suggested by 
Unitt et al.. with the system and method of Song et al., with the motivation being to allow 
multiple users to view the same video or work on the same application at the same time 
in real time. 
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6. Claims 13-16 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Song et al. in view of Unitt et al. and further in view of the Applicant's admitted prior art. 

With respect to claim 13, Song et al. discloses a network element (See 
sections 3.1-3.3 of Song et al. for reference to an Ethernet switch, a CMTS, and a 
DSLAM, which are different types of networl( elements). Song et al. also discloses 
translating a layer 3 multicast channel to a layer 2 multicast channel (See part B in 
section 2 of Song et al. for reference to using an IP address of a channel, which is 
a layer 3 address, to create an Ethernet multicast address of a channel, which is a 
layer 2 address). Song et al. further discloses encapsulating the multicast packet with 
a PPPoE encapsulation, indicating the layer 2 multicast channel and a PPPoE multicast 
session identifier in the PPPoE encapsulation, and transmitting the encapsulated 
multicast packet (See part B in section 2 of Song et al. for reference to receiving a 
multicast IP packet that is to be sent, encapsulating the packet with a PPPoE 
encapsulation that identifies the frame as a multicast session using the 
ETHERJTYPE field and indicates the specific multicast channel using an Ethernet 
multicast address, and for reference to sending, or transmitting, the encapsulated 
multicast packet). Song et al. does not specifically disclose using a control engine and 
a forwarding engine. Song et al. also does not specifically disclose using a delivery 
protocol. 

With respect to claims 14-15, Song et al. does not disclose that the control 
engine and the forwarding engine comprise one or more processors and a memory. 
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With respect to claim 13-15, Unitt et al., in the field of communications, 
discloses using a control engine and a forwarding engine comprising one or more 
processors and a memory (See page 3 paragraph 43 and Figure 1 of Unitt et al. for 
reference to a routing forwarding multicast Etiiernet packets with the routing 
including a packet forwarder 111, which is a forwarding engine, and a signal 
processor 112, which is a control engine with these devices comprising a 
processor an a memory from which the processor executes Instructions). Using a 
control engine and a forwarding engine has the advantage of separating the functions of 
transmitting multicast Ethernet packets such that the operation of either the control 
engine or the forwarding engine may be changed independently of each other. 

It would have been obvious for one or ordinary skill in the art at the time of the 
invention, when presented with the work of Unitt et al., to combine using a control 
engine and a forwarding engine, as suggested by Unitt et al., with the system and 
method of Song et al., with the motivation being to separate the functions of transmitting 
multicast Ethernet packets such that the operation of either the control engine or the 
forwarding engine may be changed independently of each other. 

With respect to claim 16, the combination of Song et al. and Unitt et al. does 
not disclose that the delivery protocol is the ATM protocol. 

With respect to claims 13 and 16, the Applicant's admitted prior art discloses 
using a delivery protocol that is the ATM protocol (See page 4 paragraph 9 of the 
Applicant's Background of the invention section for reference to using a delivery 
protocol, that may be the ATM protocol). Using ATM as a delivery protocol has the 
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advantage of allowing the protocol of the core network to be different than the protocol 
of the edge networks such that traffic may be more quickly and efficiently routed through 
the core network. 

It would have been obvious for one or ordinary skill in the art at the time of the 
invention, when presented with the Applicant's admitted prior art, to combine using ATM 
as a delivery protocol, as suggested by the Applicant's admitted prior art, with the 
system and method of Song et al. and Unitt et al., with the motivation being to allow the 
protocol of the core network to be different than the protocol of the edge networks such 
that traffic may be more quickly and efficiently routed through the core network. 

7. Claims 17-18 and 28-31 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Song et al. in view of O'Dell et al. (U.S. Pat. 6891825). 

With respect to claim 17, Song et al. discloses an apparatus (See sections 
3.1.3-3 of Song et al. for reference to the PCs, which are apparatuses of the 
different embodiments). Song et al. also discloses listening for multicast traffic on a 
layer 2 multicast channel (See part B in section 2 of Song et al. for reference to a 
client accepting Ethernet multicast packets if the client has joined the group 
receiving the Ethernet multicast packets, meaning that the client must listen for 
the multicast traffic on the layer 2 multicast channel In order to receive the 
Ethernet multicast packets). Song et al. further discloses indicating the layer 2 
multicast channel (See parts B-D in section 2 of Song et al. for reference to 
indicating the layer 2 multicast channel by the Ethernet multicast address that 
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identifies the channel). Song et al. also discloses receiving PPPoE multicast traffic, 
decapsulating the traffic from PPPoE and processing tine traffic (See part B in section 
2 of Song et al. for reference to a client receiving an Ethernet multicast packet 
and accepting the packet meaning the client device must decapsulate the packet 
and process the packet to use the packet). Song et al. does not specifically disclose 
that the apparatus includes a network interface card and a PPPoE module. 

With respect to claim 28, Song et al. discloses performing operations including 
requesting a PPPoE session (See part C in section 2 of Song et al. for reference to 
requesting a multicast PPPoE session by using a JoinLocalGroup operation). 
Song et al. also discloses transmitting an indication of PPPoE multicast capability (See 
part D in section 2 of Song et al. for reference to indicating a PPPoE multicast 
capability using a TYPE field). Song et al. further discloses generating a layer 2 
multicast channel from a layer 3 multicast channel (See part B in section 2 of Song et 
al. for reference to using an IP address of a channel, which is a layer 3 address, to 
create an Ethernet multicast address of a channel, which is a layer 2 address). 
Song et al. also discloses receiving a packet of the multicast having a PPPoE 
encapsulation, determining if the PPPoE encapsulation indicates the layer 2 channel, 
decapsulating the packet if it does indicate the channel, and discarding the packet if it 
does not (See part B in section 2 of Song et al. for reference to a PPPoE node 
accepting an Ethernet multicast packet if it has joined the multicast group and 
not accepting the packet if it has not, meaning that the packet is decapsulated an 
processed If It belongs to a Joined multicast session and discarded If it does not). 
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Song et al. does not specifically disclose using a machine-readable medium with 
instructions executed by one or more processors. 

With respect to claims 17 and 28, O'Dell et al., in the field of communications, 
discloses an apparatus including a network interface card and a PPPoE module (See 
column 5 lines 34-53 and column 6 lines 9-20 of O'Dell et al. for reference to using 
an Ethernet Network Interface Card and a PPPoE client software loaded on a 
processor). Using a network interface card and a PPPoE module has the advantage of 
allowing standard network interface cards to be used in the PPPoE multicasting system 
while providing the PPPoE multicasting functionality in separate software included in the 
PPPoE module. 

It would have been obvious for one of ordinary skill in the art at the time of the 
invention, when presented with the work of O'Dell et a!., to combine using a network 
interface card and a PPPoE module, as suggested by O'Dell et al., with the system and 
method of Song et al., with the motivation being to allow standard network interface 
cards to be used in the PPPoE multicasting system while providing the PPPoE 
multicasting functionality in separate software included in the PPPoE module. 

With respect to claim 18, Song et al. discloses that the layer 2 multicast 
channel is identified by an Ethernet IVIedia Access Control address (See part B in 
section 2 of Song et al. for reference to the layer 2 multicast channel being 
identified by an Ethernet multicast address). 

With respect to claims 29-30, Song et al. discloses transmitting a PADR 
message including a multicast capability tag to an access concentrator (See parts B 
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and D of Song et al. for reference to transmitting a PADR message inciuding a 
TYPE field that contains a flag regarding the multicast capability of a client). 

With respect to claim 31, Song et al. discloses that the PPPoE multicast 
session identifier is a reserved PPPoE session identifier (See part B in section 2 of 
Song et al. for reference to setting the ETHER_TYPE field of the frame to 0x8864, 
which is a reserved value indicating a multicast PPPoE session). 

8. Claims 21 and 24-27 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Song et al. in view of Applicant's admitted prior art. 

With respect to claim 21, Song et al. discloses a system (See sections 3.1-3.3 
of Song et al. for reference to three system embodiments). Song et al. also 
discloses a network element (See sections 3.1-3.3 of Song et al. for reference to an 
Ethernet switch, a CIVITS, and a DSLAM, which are different types of network 
elements). Song et al. further discloses translating a layer 3 multicast channel to a 
layer 2 multicast channel (See part B in section 2 of Song et al. for reference to 
using an IP address of a channel, which is a layer 3 address, to create an Ethernet 
multicast address of a channel, which is a layer 2 address). Song et al. also 
discloses encapsulating the multicast packet with a PPPoE encapsulation, indicating the 
layer 2 multicast channel and a PPPoE multicast session identifier in the PPPoE 
encapsulation, and transmitting the encapsulated multicast packet (See part B in 
section 2 of Song et al. for reference to receiving a multicast IP packet that is to 
be sent, encapsulating the packet with a PPPoE encapsulation that identifies the 
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frame as a multicast session using the ETI-iER_TYPE field and indicates the 
specific multicast channel using an Ethernet multicast address, and for reference 
to sending, or transmitting, the encapsulated multicast paclcet). Song et al. further 
discloses customer premise equipment (See sections 3.1-3.3 of Song et ai. for 
reference to an Ethernet switch, a cable modem, and a xDSL modem, which are 
CPE). Song et ai. also discloses transmitting the traffic form the CPE (See sections 
3.1-3.3 for reference to sending data packets from an Ethernet switch, a cable 
modem, or a xDSL modem to a PC). Song et al. further discloses a host coupled to 
the CPE (See sections 3.1.3-3 of Song et ai. for reference to the PCs, which are 
hosts of the different embodiments). Song et al. also discloses receiving the 
multicast traffic, determining if the host is listening to the channel indicated in the traffic 
and decapsulating the traffic if the host is listening (See part B of section 2 of Song et 
al. for reference to a client receiving data for a Ethernet multicast channel, 
determining if the client has joined the multicast group identified by the data and 
accepting and decapsulating the data if the host has joined the group). Song et al. 
does not specifically disclose using a delivery protocol. 

With respect to claim 27, Song et al. discloses a bridge coupled with the 
network element to receiving the traffic and transmit the traffic to the CPE (See 
sections 3.1-3.3 for reference to sending data paclcets from an Ethernet switch, a 
cable modem, or a xDSL modem, which can be used as a bridge, to a PC). 

With respect to claims 21, the Applicant's admitted prior art discloses using a 
delivery protocol that is the ATM protocol (See page 4 paragraph 9 of the Applicant's 
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Background of the invention section for reference to using a delivery protocol, 
that may be the ATM protocol). Using ATM as a delivery protocd has the advantage 
of allowing the protocol of the core network to be different than the protocol of the edge 
networks such that traffic may be more quickly and efficiently routed through the core 
network. 

It would have been obvious for one or ordinary skill in the art at the time of the 
invention, when presented with the Applicant's admitted prior art, to combine using ATM 
as a delivery protocol, as suggested by the Applicant's admitted prior art, with the 
system and method of Song et al., with the motivation being to allow the protocol of the 
core network to be different than the protocol of the edge networks such that traffic may 
be more quickly and efficiently routed through the core network. 

With respect to claim 24, Song et al. discloses that the layer 2 multicast 
channel is identified by an Ethernet Media Access Control address (See part B in 
section 2 of Song et al. for reference to the layer 2 multicast channel being 
identified by an Ethernet multicast address). 

With respect to claim 25, Song et al. discloses that the layer 3 multicast 
channel is identified by an Internet Protocol address (See part B in section 2 of Song 
et al. for reference to the layer 3 multicast channel being identified by an IP 
multicast packet's IP address). 

With respect to claim 26, Song et al. discloses that the PPPoE multicast 
session identifier is a reserved PPPoE session identifier (See part B in section 2 of 



Application/Control Number: 10/035,506 Page 18 

Art Unit: 2665 

Song et al. for reference to setting the ETHER_TYPE field of the frame to 0x8864, 
which is a reserved value indicating a multicast PPPoE session). 

9. Claims 22-23 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Song et al. in view of Applicant's admitted prior art as applied to claims 21 and 24-27 
above, and further in view of Unitt et al. 

With respect to claims 22-23, the combination of Song et al. and the Applicant's 
admitted prior art does not specifically disclose that the multicast packets are video 
packets and collaboration application packets. 

With respect to claims 22-23, Unitt et a!., in the field of communications, 
discloses multicast Ethernet packets that are video packets and collaboration 
application packets (See page 3 paragraph 44 and page 5 paragraph 98 of Unitt et 
al. for reference to streaming video packets and for reference to streaming other 
types of multicast services including applications). Multicasting Ethernet packets 
that are video packets and collaboration application packets has the advantage of 
allowing multiple users to view the same video or work on the same application at the 
same time in real time. 

It would have been obvious for one of ordinary skill in the art at the time of the 
invention, when presented with the work of Unitt et al., to combine multicasting Ethernet 
packets that are video packets and collaboration application packets, as suggested by 
Unitt et al., with the system and method of Song et al. and the Applicant's admitted prior 



Application/Control Number: 10/035,506 Page 19 

Art Unit: 2665 

art, with the motivation being to allow multiple users to view the same video or work on 
the same application at the same time in real time. 

10. Claims 19-20 and 32-33 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Song et al. in view of O'Dell et al. as applied to claims 17-18 and 28- 
31 above, and further in view of Unitt et al. 

With respect to claims 19-20 and 32-33, the combination of Song et al. and 
O'Dell et al. does not specifically disclose the multicast packets are video packets, 
collaboration application packets, audio packets, and ticker data packets. 

With respect to claims 19-20 and 32-33, Unitt et al., in the field of 
communications, discloses multicast Ethernet packets that are video packets, 
collaboration application packets, audio packets, and ticker data packets (See page 3 
paragraph 44 and page 5 paragraph 98 of Unitt et al. for reference to streaming 
video packets and for reference to streaming other types of multicast services 
including applications, audio, and other types of streaming data). Multicasting 
Ethernet packets that are video packets, collaboration application packets, audio 
packets, and ticker data packets has the advantage of allowing multiple users to view 
the same data or work on the same application at the same time in real time. 

It would have been obvious for one of ordinary skill in the art at the time of the 
invention, when presented with the work of Unitt et al., to combine multicasting Ethernet 
packets that are video packets, collaboration application packets, audio packets, and 
ticker data packets, as suggested by Unitt et al., with the system and method of Song et 
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al. and O'Dell et al., with the motivation being to allow multiple users to view the same 
data or work on the same application at the same time in real time. 



Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Jason E. Mattis whose telephone number is (571) 272- 
3154. The examiner can normally be reached on M-F 8AM-4:30PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Huy Vu can be reached on (571 ) 272-31 55, The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-21 7-91 97 (toll-free). 
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